Amiga Collections: MegaDisc/MegaDisc 08 (1988)(MegaDisc Digital Publishing)(AU)[WB].zip/MegaDisc 08 (1988)(MegaDisc Digital Publishing)(AU)[WB].adf/ARTICLES/1.3_System

Text File | 1988-05-28 | 23KB | 571 lines

        What is new in Workbench 1.3
        ****************************

             by James Lawrence

     [Ed: This article covers some of the new features as far as
     the writer knows - however, we'll have to wait for the final
     release, said to be in mid-October, until we know the whole
     story.]

Workbench 1.3 has been out on gamma test release now for a few months.
There are a number of significant improvements which have been made, some
of which I will describe here.  Time and space and lack of information
preclude a full discussion of all the changes, however I will try to at
least mention all those I know of.

In this article I discuss things in the order listed below.  Not
everything will be of immediate interest to everyone, so I have made
headings that stand out, so you can browse more easily and read things
in order of interest.

Fast Filing System (FFS)
Recoverable Ram Disk
NEWCON:
PIPE:
Preferences and new Printer Drivers and printer.device (See "Print.Manual")
Shell
New Commands
A note about compatibility with ARP

Fast Filing System (FFS)
########################

    At a grass roots level, there is a new hard disk filing
system, called the Fast Filing System.  As the name suggests, this
speeds hard disk use.  Without going into too much detail, the old
filing system stored 24 bytes of header info and 488 bytes of data
in each block.  Because of this, the old system read data one block
at a time, even though files were written in consecutive blocks
wherever possible.  By storing nothing but data in the data blocks,
and allocating contiguous areas of the disk (ie areas with lots of
free blocks in a row, with no breaks) wherever possible, Fast
Filing System can read and write large amounts of data in one go.
This speeds things up considerably.  It is a little hard to say just
how much it will speed up disk accesses, as this depends on the
hardware and the fragmentation of the file being dealt with.  This is
in contrast to the older system, where a much faster drive did not
necessarily give faster operation, and access is just as slow even if
the file is in one contiguous chunk of disk. I have heard reports of a
5 to 20 times increase in the speed of your typical disk access, and a
40 times increase in the speed of validating a drive.  This is because
under the new system, the software can transfer data as fast as the
hardware can, whereas under the old system, the software had to think
and issue new commands between each block transferred, so the hardware
bandwidth capability was never realised.
    Note that the fast filing system applies only to hard disks at
present, though 1.4 will also apply to floppy disks. Also, the hard disk
must be formatted under FFS, which is a major operation for someone who
already uses a hard disk.  I recommend that even if you have one of the
gamma release versions, you wait for the official release.  I have heard
of people having problems with the gamma FFS to the extent that they
have reverted to the old system until they get a more bug free version,
which the official release will be.  Hard disk problems can be a real
hassle, so it is better to avoid them.

Recoverable Ram Disk
####################

    [Ed: There are a couple of versions around of the RRD, one of
which actually warm boots off itself - ie, you don't need a disk in the
drive, very useful. The final form of the RRD is not yet clear, however so
the comments below are as a guide only.]

    Have you ever put a whole lot of stuff in RAM: and then had to
reboot?  You lost it all, didn't you?  Well, now there is a device
called CARD: which is similar to RAM:, but doesn't disappear when you
do a warm boot (ctrl-amiga-amiga).  Before you read any further, let me
warn you that it will only be useful to you if you have more than a
megabyte of memory, as it is of a fixed size, not dynamic like RAM:
(although you can change the size in the Mountlist, ie "highcyl").
Typically, it will take up 880k.  The similarity between CARD: and RAM:
is that they both reside in memory, but other than that, CARD: actually
behaves more like a floppy disk.  As far as I can ascertain, the system
treats CARD: as if it really is a floppy disk.  This means that you can
do things like use DISKCOPY to copy the entire contents of the workbench
disk onto CARD:, then run everything from there.  I do just that, in my
startup-sequence (see the article elsewhere in this issue dealing with
startup-sequences), and every command I issue is executed with lightning
speed.  It also means I can get away quite comfortably using only one
disk drive.  Before I discovered CARD:, I used to do a similar thing
with RAM:.  However, because diskcopy does not work with RAM:, and I had
to copy the disk file by file with every boot (ie I did a
          copy df0: to ram: all quiet
in my startup sequence), a boot used to take about 4 minutes.  I replaced
this line with the following:

mount card:
if exists card:c then
    echo "card: found intact"
else
    diskcopy df0: to card:
endif

Now a cold boot (turning the machine on) takes about 100 seconds, and a
warm boot about 45 seconds, as all the stuff in CARD: is already there.
As the code segment above suggests, CARD: must be mounted with each boot,
but will still contain its old files after a warm boot.
    There are other uses for a recoverable ram disk, such as speeding
disk duplication on a single floppy system.  Doing a diskcopy (from CLI
or workbench) from df0: to card:, then from card: to df0:, is faster and
avoids all the disk swapping involved in a normal single drive diskcopy.
With imagination, you could come up with other good uses.  For the
intrepid explorer, try having a look at the CARD: entry in the file
devs:mountlist.  It looks remarkably similar to a floppy disk entry.
You can modify the size of the drive by varying the LOWCYL & HIGHCYL
values.  Of course, to see the effect of this, CARD: has to be mounted
after you modify the file.  If it is already mounted, you will have to
reboot unless you know a way to dismount a device.  I certainly don't.
Only one CARD: may be mounted at once, which is a bit of a pity.  The
guys at the Commodore tech group tell me that you can mount one big CARD:,
then put smaller partitions in it in similar style to partitioning a
hard disk, but I have not had any success with this.
    If you have an A1000 and kickstart 1.3 then you will even be able
to warm boot from CARD:.
    In case you were wondering, CARD stands for Commodore Amiga Ram
Drive.

NEWCON:
#######
    As the name suggests, this is a new version of CON:.  It allows
command line editing and keeps a command history, both done using the
arrow keys. It is used by the Shell.
    Left and right arrows move over the text for editing.  Shift-left
and shift-right go to the ends of the line.
    Up gives you the previous command, more ups get you back earlier.
Down gives later commands in case you go back too far (but of course
can not give you the command you were about to type.  If someone
implements this feature, they will make a fortune!).  Shift-up finds
the latest command which starts with a partly typed string.  Shift-down
takes you straight to the bottom of the history buffer.  Once you have
found the desired command in the history, you may edit it using left
& right arrow keys, then hit return.
    In other respects, NEWCON: resembles CON:, except that it must
be mounted before use.  This would normally be done in the startup-sequence.

PIPE:
#####
    Unix buffs will be familiar with the concept of a pipe.  The idea
is that the output of one program can be redirected into the input of
another, in a similar way that output can be redirected to a file.  The
method used is, however, slightly different from unix.  One very typical
use of a pipe is to use MORE (the text-displaying utility) to slow down the
output of a program so it can be read.  A typical example would be:

mount pipe:

(this only need be done once per boot.  It could be in the
startup-sequence.)  Then, in one CLI:

dir > pipe:a df0: opt a

then in another CLI:

more pipe:a

The pipe can be considered as being like a file which can be written to
by one program and read from by another simultaneously.  As many pipes
as needed can be invoked simultaneously by using a different name, for
example pipe:b.  In this way, many commands can be strung together with
pipes between them.  It is possible to write to a pipe from an
application program (wordprocessor, etc) simply by specifying a pipe as
the name of the file to write.  Similarly, a pipe can be read in the
same way.
    The way the pipe works (roughly) is that one program
writes into a buffer, which the other program reads from.  No permanent
storage is done.  The maximum size of the buffer is 4k, so if the
writing program tries to write more than 4k past where the reading
program is up to, then it is stopped until the reading program has read
some more.


Preferences and new Printer Drivers and printer.device
######################################################


    Most of the changes to preferences relate to printers.  There
are now two printer graphic screens.  These allow you to control density,
horizontal centering, scaling, colour correction (to make the printer
output look  like the screen), left offset, dithering (making new colours
by putting different coloured pixels next to each other),size,
antialiasing (smoothing diagonal lines), and a couple of more esoteric
things.

    There are a whole swag of new and rewritten printer drivers.
Notable amongst them is the EpsonQ 24 pin driver, which allows printing
at densities of 90, 120, 180, and 360 dpi.

    Have a look at the article "Print.Manual" on this disk for the
full story about printing with the Amiga and 1.3.

Shell
#####

    This replaces the CLI.  There have been several enhancements,
including resident commands, aliasing, putting the current directory
into the prompt, and shell scripts.
    A resident command is one which is in memory permanently, so
it does not need to be loaded each time it is called.  It could be
run several times simultaneously, with all invocations using the same
piece of code in memory.  This is described further in the next section.
    Aliasing allows you to type one thing when you really mean
something completely different, but still have your Amiga understand
what you are saying.  It works like this: Imagine for a moment that
you have a directory called sys:fred/john/mary/englebert/yet_another_one
which you often want to CD to.  You could set up an alias like

alias yao cd sys:fred/john/mary/englebert/yet_another_one

Then typing

yao

would be equivalent to typing

cd sys:fred/john/mary/englebert/yet_another_one

If you need to have a variable part in the alias, then enlose it in []
eg

alias xcopy copy [] clone

then typing

xcopy fred john

would be equivalent to

copy fred john clone

Typing

alias yao

removes the definition for yao.

Typing alias by itself lists the current aliases.

1>alias
xcopy   copy [] clone
newshell    newcli newcon:0/0/640/256/AmigaShell

By the way, those two are standard.
    Each shell will maintain its own independent set of aliases.
It would be a good idea to set the ones you will use often in the
s:CLI-startup file, which is a sequence which gets executed every time
a CLI (shell) is invoked.

    The PROMPT command has been enhanced for use with the shell.
The format is

PROMPT <string>

where <string> is the prompt desired, surrounded by quotes.  Within
the string, %N gives the CLI number, and %S gives the current directory.
For example,

prompt "%N.%S > "

would give a prompt which might look like

3.SYS:fred/john/mary/englebert/yet_another_one>

(there is a space after the >) This is the default setting.

    It is no longer necessary to use the EXECUTE command explicitly.
Instead, use PROTECT to set the script bit of the protection field.
For example, if we say

protect scriptfile +s

where scriptfile is some file containing CLI commands (a sequence),
then at any time in the future,

scriptfile

is equivalent to

execute scriptfile

If you put the S: directory in the path, then things get even easier,
as you can create scripts, store them in S:, then treat them just
like any other command.
    This feature still uses EXECUTE, so to make it really fly,
you could make EXECUTE resident as described below.


New Commands
############

ASK     Provides interactive execution control in the CLI.  This is
    only really useful in sequence files.  As an example, the
    following code segment in a sequence file:

    ask "Are you ready for this?"
    if warn then
        echo "OK, lets get under way!"
    else
        endcli
    end if

    will ask the user the question.  If the answer is y or yes
    (in upper or lower case), then ASK sets a return code of 5
    (warn), and the echo is done.  Any other response will
    cause the ELSE section to be executed (in this example this
    terminates the sequence).  [Ed: check SWITCH in the PROGRAMS
    drawer for a mouse-driven ASK.]

AVAIL   Gives memory usage & availability statistics.

    1> avail
    Type  Available    In-Use   Maximum   Largest
    chip     366272    156960    523232    362416
    fast    1452656   1161352   2614008    954472
    total   1818928   1318312   3137240    954472

FF      stands for FastFonts.  Generally run in the startup-sequence.

GETENV & SETENV Return or set the value of an environment variable.
    A couple of examples:

    1> setenv number 25
    1> getenv number
    25
    1> setenv fred_nurk "silly person"
    1> getenv fred_nurk
    silly person
    1> getenv number
    25

    where lines starting with a prompt ( ie 1> ) are input, and
    others are output.

    SETENV with only one argument removes that variable.
    Continuing from the above example:

    1> setenv number
    1> getenv number

    (nothing is returned)  These commands are designed to use
    the ENV: device promised for V1.3.  In the author's gamma
    version, they use a directory in RAM: which has been ASSIGNed
    the name ENV:.

LOCK    Sets and resets the write protect of a hard disk or partition
    using fastfilesystem.  If you type

    LOCK "dh0,on,xxxx"

    where xxxx is an optional four letter password, then the drive
    will be write protected until you type

    LOCK "dh0:,off,xxxx"

    where xxxx is the same password (or absence of one), or until
    you reboot.

    You may need an extra comma after the 'on' and before
    the 'off'.

RESIDENT    Allows often used commands to be loaded permanently
    into memory, so subsequent calls just execute that bit of
    memory.  More than one occurrence of the program may then
    use the same piece of code, which is just to say that if we
    made a command resident, and used it in two shells
    simultaneously, then both would actually run from the same
    code segment in the same memory.  This saves both time and
    memory space.  In another way, it wastes memory, as all
    resident commands are permanently in memory regardless of
    whether they are currently being used.  This feature can only
    be used with the shell described above, it does not work with
    the old CLI.  Also, to be able to be made resident, a piece
    of code must be both re-entrant and re-executeable, which
    essentially means that it must be pure code - code which uses
    no variables buried in the code (it may use the stack, or other
    schemes for keeping variables independent of code).  This does
    limit the programs available.  A pure code segment should have
    the PURE bit set in the protection field (>protect name +p).
    It is possible to test code for purity by using resident with
    the PURE flag.  This would be done as follows:

    resident "name,file,add,pure"

    where name is what you want the command to be called, and file
    is the full pathname where it can be found.
    Then run the command simultaneously in two separate shells.  If
    all is well, then the code is pure.  If a guru happens, the code
    is impure.  If the code is pure, you can set the PURE bit:

    protect name +p

    The full specification of the command is

    resident "name,file,action,pure"

    where name and file are as described above, action is one of
    add, delete, replace, and the pure is optional (not needed if
    pure bit of file's protection field is set).  If no name is
    specified, then it defaults to the filename part of the full
    pathname.

    Normally you would set up all the resident commands in the
    startup-sequence.  See the article on startup sequences elsewhere
    in this issue.

    resident called with no arguments lists the resident list:

    1> resident

    Name         UseCount
    Execute         1
    CLI           SYSTEM
    FileHandler       SYSTEM
    Restart       SYSTEM
    CLI           SYSTEM

SETALERT    A mystery command.  Possibly it helps to avoid gurus
    - but I can assure you it does not prevent them!  In any case,
    this gets run during the startup sequence, and never goes away.

XICON   Runs a script file (a sequence) from the workbench.  To use
    this, create an icon for the file, and set the default tool to
    c:Xicon by using the workbench INFO menu item.  You may also
    set a WINDOW= specification (take a look at the SHELL (or CLI)
    icon for an example) to set the size & location of the window
    needed for input and output for the script.  You may also set a
    DELAY= to delay the demise of the window after the script is
    finished.
    [Ed: Pete Goodeve tells me that Xicon is not working in the gamma
    release version of 1.3, and it certainly isn't his program - it's
    been rewritten and is smaller.]

The following additions have been made to the SYSTEM directory:

FASTMEMFIRST    This organises the free memory list so that fast
    gets used first.  This saves chip memory for things that
    must use it - such as the chips (surprise surprise) and a few
    older programs.

FIXFONTS    ???

The following additions have been made to the UTILITIES directory:

CALCULATOR      A four function calculator driven by mouse or keyboard.

CLOCKPTR    Turns the workbench pointer into a digital clock
    whenever the Workbench is selected.  This shows the time in
    24 hour format.  If the pointer is against the left edge of
    the screen, the date is displayed.  If it is in the top left
    corner, then minutes and seconds are shown instead of hours
    and minutes.

    This can be run from either CLI or workbench - the icon is
    in the utilities folder.

    Successive invocations of CLOCKPTR toggle between the clock
    and the default pointer.  Alternatively, if you ran it from
    the CLI, you can stop it with ctrl-c or with the break command.

CMD     Redirects serial or parallel port output to a file.  This is
    useful if, like me, you do not own a printer.  You can use a
    print command in a word processor (or any application) and
    save the output on disk.  Then off you go to your friend's
    place to use his printer.  If you have a 5.25 inch drive and
    the appropriate driver, you could save the file on an MS-DOS
    disk and print it using one of those machines (perhaps take
    your disk to work and use the laser printer ...).  CMD also
    makes it possible to inspect and edit printer or modem
    before it is sent to the device in question.

    The format is
    CMD -s -m -n <devicename> <filename>
    The -s, -m, and -n are optional.
    -s skips any short initial write (usually a reset)
    -m captures multiple files until ctrl-c or a break
    -n gives progress messages (NOTIFY)

    CMD can also be used from the workbench.  To set the options,
    use the workbench menu item INFO and set the tool types.
    The default settings for these are:
    DEVICE=parallel
    FILE=ram:CMD_file
    SKIP=FALSE
    MULTIPLE=FALSE
    NOTIFY=FALSE

MORE    Like a nice version of TYPE.  Allows you to read files a page
    at a time, search for strings, etc.  For a list of commands,
    type the letter h to the more prompt.  The format is simply
    MORE filename

    MORE can be run from the workbench by selecting the file
    (click on it), then holding the shift key while you double
    click on MORE.

SAY     Pretty much like the current one.

Many of the existing commands have slightly changed specifications,
too many to list here.  I can only suggest that you wait for official
documentation, or if you are playing with the system, then you can at
least find the templates by typing command ?
For example, consider the humble COPY command:

1>copy ?
FROM,TO/A,ALL/S,QUIET/S,BUF=BUFFER/K,CLONE/S,DATE/S,NOPRO/S,COM/S:

The BUF= option sets the number of 512 byte buffers used by COPY.
DATE, NOPRO, and COM allow the initial date, protection and
comment respectively to be reproduced.  CLONE does all three in
one hit.
Experiment with your favourite commands and see if they have changed!

A note about compatibility with ARP
###################################

[Ed: See review this issue and on previous issues.]

    The Amiga Replacement Project (ARP) is a set of Amigados
commands written  by a third party wth the following properties:
  they are compatible with WB1.2
  they are written in assembler, which makes them faster and smaller
than their Commodore V1.2 commands written in C
  they have a more consistent set of options
  a few other improvements over V1.2

    Commodore's V1.3 commands are also
  compatible with WB1.2
  written in assembler
  have a more consistent set of options
  have a significant number of improvements over V1.2
In addition, many of the V1.3 commands have features which are V1.3
specific.  For example, PROTECT now gives access to the pure, script,
hidden and archive flags.  The pure and script flags are relevant
only to resident commands and directly executeable shellscripts
respectively, which are features of the new shell.  What the hidden
flag does is anybody's guess.  More importantly, the V1.3 commands
were written specifically to be pure code, so they can be made
resident.  I do not know whether the ARP people had this in mind
when they wrote their commands, so ARP may or may not be pure.
One way to find out would be to use the PURE option to RESIDENT, as
described above.  In any case, it would not be sensible to simply
replace all the V1.3 commands without the ARP ones.  Each command
would have to be looked at on its own merit, and I strongly suspect
that the performance gain available is very limited, and not worth
the effort.  This is in contrast to V1.2, where ARP is definitely
an improvement.  Mind you I have not looked at ARP in depth, so I
could be completely wrong ... .


If you have learned half as much by reading this article as I have
by writing it, then you are well on your way to being able to
utilise the full potential of your Amiga under WB1.3.

Happy hacking,
James.

XXXXXXXXXXXXXXXXXXXXXXXXX END OF 1.3_SYSTEM XXXXXXXXXXXXXXXXXXXXXXXXXXXXX